Dynamic rule generation for an enterprise intrusion detection system

ABSTRACT

A method for dynamically generating rules for an enterprise intrusion detection system comprises receiving a packet flow from a sensor. The packet flow is dynamically processed to detect if the packet flow represents an attack on the enterprise system. A response message is automatically generated in response to the attack, the response message comprising a signature to identify the attack. The response message is automatically communicated to a response message file, the response message file comprising at least one response message.

RELATED APPLICATIONS

This application is related to:

U.S. application Ser. No. 10/407,513 (now U.S. Pat. No. 7,356,585) for a“VERTICALLY EXTENSIBLE INTRUSION DETECTION SYSTEM AND METHOD,” Apr. 4,2003 by Jon-Michael C. Brook, Matthew C. Rixon, Randall S. Brooks, andTroy Dean Rockwood (064750.0465); and

U.S. application Ser. No. 10/407,030 for a “GRAPHICAL USER INTERFACE FORAN ENTERPRISE INTRUSION DETECTION SYSTEM,” Apr. 4, 2003 by Jon-MichaelC. Brook, Matthew C. Rixon, Randall S. Brooks, and Troy Dean Rockwood(064750.0472).

TECHNICAL FIELD OF THE INVENTION

This invention relates to intrusion detection systems and, morespecifically, to dynamic rule generation for an enterprise intrusiondetection system.

BACKGROUND OF THE INVENTION

Intrusion detection systems are used by an enterprise to detect andidentify unauthorized or unwanted use (commonly called an attack) of theenterprise's computer network, which normally comprises a large numberof nodes and network operations centers (NOCs). In general, theseenterprise intrusion detection systems scan incoming data for specificpatterns in network traffic, audit trails, and other data sources todetect malicious activity. Due to the large quantity of data,conventional intrusion detection systems often use many analysts toevaluate network data with various tool implementations for identifyingthe patterns, such as finite state machines, simple pattern matching, orspecialized algorithms.

Traditional enterprise intrusion detection systems (IDSs) do not includean ability to quickly and dynamically update intrusion signatures at alarge number of nodes. Often this is due to the lack of reliablescalability of the IDS and\or poor communication between variouscomponents of the IDS across an enterprise. Additionally, conventionalIDSs normally do not include the capability to effectively detect orrespond to long-term attacks.

SUMMARY OF THE INVENTION

In accordance with the present invention, the disadvantages and problemsassociated with traditional enterprise intrusion detection systems havebeen substantially reduced or eliminated.

One aspect of the invention is a method for dynamically generating rulesfor an enterprise intrusion detection system comprises receiving apacket flow from a sensor. The packet flow is dynamically processed todetect if the packet flow represents an attack on the enterprise system.A response message is automatically generated in response to the attack,the response message comprising a signature to identify the attack. Theresponse message is automatically communicated to a response messagefile, the response message file comprising at least one responsemessage.

The invention has several important technical advantages. Variousembodiments of the invention may have none, some, or all of theseadvantages. One advantage of the present invention might be an abilityto collect more information that allows slow or low-level attacks to bedetected. Further potential advantages include enterprise-widedeployment of dynamic signatures in response to an attack, or reducingthe volume of information passed between various system or networklevels. Other technical advantages of the present invention will bereadily apparent to one skilled in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and itsadvantages, reference is now made to the following descriptions, takenin conjunction with the accompanying drawings, in which:

FIG. 1 illustrates a portion of a vertically extensible intrusiondetection system according to various embodiments of the presentinvention;

FIG. 2 illustrates an embodiment of a sensor in accordance with thesystem of FIG. 1;

FIGS. 3A-C illustrate various embodiments of a correlation engine of thesystem of FIG. 1;

FIG. 4 illustrates an embodiment of a graphical user interface inaccordance with the system of FIG. 1;

FIG. 5 illustrates an embodiment of a hash table used by the graphicaluser interface of FIG. 4;

FIG. 6 is a flowchart illustrating a method for aggregating a pluralityof flows in accordance with the vertically extensible intrusiondetection system of FIG. 1;

FIG. 7 is a flowchart illustrating a method for dynamic rule generationin accordance with the vertically extensible intrusion detection systemof FIG. 1; and

FIG. 8 is a flow chart illustrating a method for generating a userinterface using sorted packet flows for use by graphical user interfaceof FIG. 4.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS OF THE INVENTION

FIG. 1 illustrates a portion of a vertically extensible intrusiondetection system 10 distributed across an enterprise system according tovarious embodiments of the present invention. The “enterprise” maycomprise any business, government, organization, or other large entitythat has multiple network channels or ports to an external network 100.For example, a business enterprise may include four ports for externalnetwork communications including email, internet, and dialup. In thisexample, intrusion detection system 10 monitors network communicationson the three external ports and attempts to detect, locate, or block anattack on the business. An “attack” may be any malicious, destructive,or suspicious activity communicated from a source external to theportion of the enterprise protected by system 10. Attacks may includeviruses, Trojan horses, worms, or any other piece of code or data thatrepresents at least a portion of an unwanted attempt to access theprotected portion of the enterprise. Returning to the example, oneattack on the business may comprise two different packets, eachcommunicated from the same source but through a different network port.Another attack may comprise two different packets communicatedseparately over a substantial length of time. These attacks and those ofsimilar nature may not be detected by firewalls, sensors, or othertraditional intrusion detection systems.

According to certain embodiments, intrusion detection system 10comprises multiple logical levels, each level operable to control,monitor, or update lower logical levels. Each level further providescombinatorial detection across a plurality of logically-lower nodes. Inshort, system 10 provides the enterprise with, at a minimum, verticallyand horizontally extensible intrusion detection. Vertically extensiblegenerally means that system 10 may easily add an additional logicallevel (comprising one or more servers) providing further combinatorialdetection across the plurality of logically lower nodes and/or reducedinformation to levels located logically higher than the added level.

Intrusion detection system 10 comprises a plurality of sensors 20, oneor more manager servers 30, global server 40, and console 50. Generally,intrusion detection system 10 may hierarchically couple manager servers30 such that multiple levels exist. For example, system 10 may includefour levels: sensor level 120, manager server lower-level 130 b, managerserver (or master server) upper-level 130 a, and global server 40.Accordingly, intrusion detection system 10 is vertically extensible anddynamically responds to attacks on the enterprise. It will be understoodthat system 10 comprises any number of levels and, thus, issignificantly scaleable across the enterprise. Each level detects anattack on the enterprise system based on communications from lowerlevels, dynamically responds to the attack, and, when appropriate,automatically communicates response messages to lower levels. It shouldbe understood that the levels represent logical levels as opposed tophysical systems and that one or more modules or levels of system 10 maybe included in the same computing device. Further, the term“automatically,” as used herein, generally means that the appropriateprocessing is substantially performed by system 10. It should beunderstood that automatically further contemplates any suitable userinteraction with system 10.

The various levels in the hierarchy are located in a portion of internalnetwork 80. Internal network 80 may include one or more intranets, localarea networks (LANs), metropolitan area networks (MANs), wide areanetworks (WANs), or any other suitable enterprise network. Network 80may, for example, communicate Internet Protocol (IP) packets, framerelay frames, Asynchronous Transfer Mode (ATM) cells, and/or othersuitable messages between network addresses. According to particularembodiments, messages between the levels may be in one or more formatsincluding Intrusion Detection Message Exchange Format (IDMEF), binaryformat, and/or any other appropriate format. Generally, the messagesinclude at least packet flows 70, alert messages 71, response messages72, processing messages 73, and archival data 74. Each packet flow 70 isa plurality of network packet headers passed up through the levels.According to certain embodiments, packet flow 70 represents acompression of all or a portion of packet information sent from anexternal source IP address to an internal destination IP address withina set timeframe, normally from the TCP handshake to the TCPreset/timeout. In another embodiment, packet flow 70 may include acompression of subnet communications to other IP addresses or subnets,UDP communications, or ARP communications. Alert messages 71 may be anycommunication that alerts a higher level of a possible attack such as,for example, IDMEF IDS alerts. Each response message 72 comprises anintrusion signature, rule, or instruction that is used by at least onenode to detect, identify, or impede an attack on the enterprise system.As used herein, response messages 72 include static and dynamic responsemessages. Processing messages 73 comprise commands sent from one node insystem 10 to another node such as, for example, from manager server 30to sensor 20. Archival data 74 generally comprises the full set ofinformation and data associated with an attempt to access internalnetwork 80 and may be created using any appropriate technique. Forexample, archival data 74 may be created by a “TCPDump” command toinclude all data communicated between the source IP address to thedestination address in binary format. Messages may include any othersuitable communication operable to communicated from a node andprocessed by other nodes or levels. Any or all of the communications maybe secured through associating the respective message with a firstverification value or digital signature that may be decoded by thereceiving node without departing from the scope of this disclosure.Accordingly, each node may be operable to compute a second verificationvalue based on the communication and, in response to the first andsecond verification values not being equal, refuse the communication.

External network 100 represents any network not protected by intrusiondetection system 10. Accordingly, external network communicably couplessystem 10 and external computer systems. Network 100 may, for example,communicate Internet Protocol (IP) packets, frame relay frames,Asynchronous Transfer Mode (ATM) cells, and/or other suitableinformation between network addresses. Network 100 may include one ormore intranets, local area networks (LANs), metropolitan area networks(MANs), wide area networks (WANs), all or a portion of the Internet,and/or any other communication system or systems at one or morelocations. The external client system (not shown) may be any computer,enterprise or non-enterprise, which is trying to access the portion ofinternal network 80 protected by intrusion detection system 10. As usedin this document, the term “computer” is intended to encompass apersonal computer, terminal, workstation, network computer, kiosk,wireless data port, wireless telephone, personal digital assistant(PDA), one or more processors within these or other devices, or anyother suitable processing device.

As described earlier, intrusion detection system 10 comprises aplurality of levels with each level comprising nodes such as sensors 20,one or more manager servers 30, global server 40, and console 50. In theillustrated example, system 10 comprises server level 120 comprising aplurality of sensors 20, manager server level 130 b comprising aplurality of manager servers 30 b, and master server level 130 acomprising one or more master servers 30 a. Each sensor 20 is located ata network port that receives TCP/IP packets or other similar networkcommunications from external network 100. Generally, sensor 20 processesthe raw data to detect the presence of an attack and outputs at leastthe raw data and, when appropriate, a corresponding alert message 71. Incertain embodiments, sensor 20 may also generate messages, such as apacket flow 70, based on the raw data received from external network100.

Sensor 20 may use any suitable detection technique to process incomingdata and output the appropriate messages. For example, sensor 20 may usealgorithms, signatures, scripts, or any suitable detection or comparisontechnique to process packet headers, packet payloads, and/or any otherincoming data. Sensor 20 could include any hardware, software, firmware,or combination thereof operable to receive data from external sourcesvia network 100, process the raw network data, and communicate resultsto higher levels. For example, sensor 20 may comprise a computer,server, lower-level intrusion detection system, firewall, or any modulewritten in any appropriate computer language such as, for example, C,C++, Java, Perl, and others. It will be understood that while sensor 20is illustrated as a single multi-tasked module, the features andfunctionality performed by this engine may be performed by multiplemodules such as for example, a sensor module and a packet flowgeneration module. Additionally, to help ensure that each port isproperly monitored, each sensor 20 may be associated with a redundantslave sensor, illustrated as slave sensor 20 b, which is operable toassume substantially all of the functionality of the sensor 20 in theevent of any failure of sensor 20.

In one embodiment, sensor 20 processes each incoming packet according toa response message file 25. Response message file 25 may include XMLtables, flat files, CSV files, SQL statements, relational databasetables, HTML pages, or any other appropriate data structure to store atleast one response message 72. System 10 may include one responsemessage file 25 for use by a plurality of sensors 20 or one responsemessage file 25 per sensor 20, as appropriate. In other words, responsemessage file 25 may be separated into multiple tables, consolidated intoone table, or stored inside sensor 20, without departing from the scopeof the disclosure. As described in more detail in FIG. 3C, upper levelsof system 10 dynamically generate response messages 72 based on adetected attack and communicate these response messages 72 to theappropriate response message files 25 through manager servers 30. Eachresponse message file 25 may further include static response messages72. Static response messages 72 may be stored in a database, encryptedwith a hash value, and communicated to identifiable portions of entiresystem 10 such as, for example, all sensors 20 behind enterprisefirewalls.

Manager server 30 represents any hardware or software module thatcontrols or monitors one or more servant nodes. In one example, eachmanager server 30 includes a correlation engine 31 and a correlationruleset 33, described in more detail in FIGS. 3A through 3C, forreceiving and correlating data from lower-level nodes. Generally,through correlating and aggregating lower-level communications, managerserver 30 is capable of detecting an attack occurring across multipleservant nodes and dynamically responding to such a threat. The servantnodes may include sensors 20 or lower-level manager servers 30. Forreadability purposes, the term master server may be used to describe anupper-level manager server 30 which has other manager servers 30 asservant nodes. Normally, one or more lowest-level manager servers 30control and monitor a plurality of sensors 20. In certain embodiments,each low-level manager server 30 may receive raw data from sensors 20,such as in binary format, and generate packet flow 70 for use byupper-level manager servers 30.

According to certain embodiments, manager server 30 comprises ageneral-purpose personal computer (PC), a Macintosh, a workstation, aUnix-based computer, a server computer, or any other suitable processingdevice. Additionally, to make system 10 more robust, each manager server30 may be associated with a redundant manager server, illustrated asmanager server 30 b, which is operable to assume substantially all ofthe functionality of manager server 30 in the event of a failure of theassociated manager server 30. Although FIG. 1 provides one example of aserver 30 that may be used with the invention, system 10 can beimplemented using computers other than servers, as well as a serverpool. Manager server 30 may include any hardware, software, firmware, orcombination thereof operable to receive communications from lowerlevels, appropriately process the communications, and dynamicallyrespond. According to one embodiment, manager server 30 may comprise aweb server. One function of manager server 30 might be to allow anexternal client to send or receive content over or from the Internetusing a standard user interface language such as, for example, theExtensible Markup Language (XML) or Hypertext Markup Language (HTML).Manager server 30 would then include sensors 20 that can accept datafrom the external client via a web browser (e.g., Microsoft InternetExplorer or Netscape Navigator) and return the appropriate HTMLresponses.

At the highest logical level, system 10 comprises global server 40.Generally, global server 40 is operable to receive alert messages 71,response messages 72, and archival data 74 from each node in system 10and ensure that response messages 72 are distributed to the appropriatelower nodes. It should be understood that global server 40 may furtherinclude functionality similar to that described in regard to managerserver 30. For example, global server 40 may communicate a firstresponse message 72 to every sensor 20 via the manager server 30 levels.In another example, global server 40 may determine that only a portionof sensors 20 would benefit from a second response message 72 and, thus,communicates second response message 72 to only the appropriate managerservers 30 in the hierarchy. Global server 40 may comprise ageneral-purpose personal computer (PC), a workstation, a Unix-basedcomputer, a server computer, or any other suitable device. Although FIG.1 provides one example of global server 40 that may be used with theinvention, system 10 can be implemented using computers other thanservers, as well as a server pool. Global server 40 may include anyhardware, software, firmware, or combination thereof operable to processcontrol and monitor system 10 at the highest logical level.

Global server 40 may include an archive database 45 to store the rawarchival data 74 for later processing, retrieval, or searches. Archivedatabase 45 may include any memory or database module and may take theform of volatile or non-volatile memory comprising, without limitation,magnetic media, optical media, random access memory (RAM), read-onlymemory (ROM), removable media, or any other suitable local or remotememory component. In one embodiment, archive database 45 comprisesstored IP information such as, for example, TCPDump data correspondingto each packet flow 70. Archive database 45 may include any other datasuch as, for example, historical operator commands or response messages72 previously communicated to lower nodes without departing from thescope of this disclosure. Global server 40 may include a globalcorrelation engine 31 that is further operable to process archivedatabase 45 to detect the presence of a substantially long-term ormulti-staged attack that had previously gone undetected by sensors 20and manager servers 30 using packet flows 70. Although FIG. 1illustrates archive database 45 as residing internally to global server40, archive database 45 may reside externally or at any other locationor locations accessible by global server 40.

Global server 40 further may comprise a filtering ruleset 47. Filteringruleset 47 allows system 10 to reduce the analyst's workload throughfiltering the information communicated to console 50. Ruleset 47comprises instructions, algorithms, or any other directive which largelycontrols the information communicated to console 50. Although FIG. 1illustrates filtering ruleset 47 as residing internally to global server40, filtering ruleset 47 may reside externally at one or more managerservers 30 or at console 50 without departing from the scope of thisdisclosure.

Intrusion detection system 10 may communicate the resulting informationto console 50 so that a user, such as a supervisor or administrator, mayview the desired packet flows 70 and alert messages 71. System 10 mayfilter the communications to console 50 based on the filtering ruleset47. Console 50 also allows the communication of static response messages72 to global server 40 for distribution to the appropriate lower nodes.Console 50 may represent any computer that may comprise input devices,output devices, mass storage media, processors, memory, or othercomponents for receiving, processing, storing, and/or communicatinginformation. It will be understood that there may be any number ofconsoles 50 coupled to network 100 such as, for example, one or moreoperator or analyst consoles 50 and a supervisor console 50.

Console 50 is communicably connected to global server 40 viacommunications channel 55, which may be direct-line, encrypted, or anyother type of substantially secure communication channel. The securityof communications channel 55 helps ensure that any static responsemessages 72 that global server 40 receives via channel 55 is from theappropriate console 50—not from an external or unauthorized source.According to certain embodiments, communications channel 55 may utilizeSecure Sockets Layer (SSL) technology. SSL is a transport leveltechnology for authentication and data encryption between two nodes on anetwork. SSL negotiates point-to-point security between console 50 andglobal server 40. It sends data over a “socket”, a secure channel at theconnection layer existing in most TCP/IP applications. Information beingtransmitted via communications channel 55 is encrypted and only therespective console 50 and global server 40 have the key and, therefore,the ability to understand and decipher transferred information. Console50 may be, alternatively or additionally, linked to one or more masterservers 30 without departing from the scope of this disclosure.

Console 50 may include a graphical user interface (GUI) 52 that tailorsand filters the data presented to the user, illustrated in more detailin FIG. 4. Generally, GUI 52 provides the user of console 50 with anefficient and user-friendly presentation of data and events occurring insystem 10. GUI 52 may open a secure shell (SSH) tunnel to provideadditional secure communications between console 50 and the otherportions of system 10. GUI 52 may comprise a plurality of displayshaving interactive fields, pull-down lists, and buttons operated by theuser. In one example, GUI 52 presents the descriptive information ofeach packet flow 70 to the user and conceals the remaining informationin order to reduce visual clutter. Then, upon receiving a request fromthe user, GUI 52 expands the visual representation of packet flow 70 tofurther display the packet headers and payloads to the user. GUI 52 mayinclude multiple levels of abstraction including groupings andboundaries. It should be understood that the term graphical userinterface may be used in the singular or in the plural to describe oneor more graphical user interfaces and each of the displays of aparticular graphical user interface. Further, GUI 52 contemplates anygraphical user interface that processes information from verticallyextensible intrusion detection system 10, or other appropriate system,and efficiently presents the information to a user.

In one aspect of operation, manager server 30 communicates processingmessage 73 to sensor 20 to ensure that sensor 20 operates according to aparticular set of criteria such as, for example, periodically pollingresponse message file 25 for current and expired response messages 72.Accordingly, sensor 20 monitors the respective port in network 80 whenthe port receives a request to initiate communications from an externalcomputer via external network 100. Once the communication session isinitiated, sensor 20 begins processing substantially all of the datacommunicated from the external system based on response message file 25.After processing the packets, sensor 20 communicates the raw IP archivaldata 74, in binary format, to low-level manager server 30. If sensor 20determines that one or more packets represents a portion of an attack onthe enterprise, then sensor 20 generates an alert message 71. In certainembodiments, sensor 20 may combine a plurality of packets into packetflow 70 based on any appropriate criteria such as, for example, sourceaddress, destination address, or packet payload and assign a priority tothe generated packet flow 70. For example, to reduce the data processedby upper levels, sensor 20 may only compress a plurality of packets topacket flow 70 if one of the packets represents at least a portion of anattack. In another example, sensor 20 may combine all plurality ofpackets into packet flows 70. One example packet flow 70 comprisesdescriptive information, packet headers, and the assigned priority andis in IDMEF format. The descriptive information may include the count ofpackets in the packet flow, a timestamp, a class, or any other suitabledata. Sensor 20 then associates the alert message 71 with packet flow 70and communicates packet flow 70 and the associated alert message 71 tothe supervising low-level manager server 30. The term “associated,” asused herein, may mean incorporated into, linked with, or any otherlogical or physical relation.

Manager server 30 receives the data, either binary or packet flow 70,from sensors 20. If the data is received in binary format, thenlow-level manager server 30 reduces the data to packet flows 70 based onany appropriate criteria such as, for example, source address,destination address, or packet payload. Once packet flows 70 arereceived or generated, manager server 30 correlates packet flows 70 withany associated alert messages 71. Based on this correlation, managerserver 30 assigns a priority to packet flow 70. Manager server 30 mayalso assign a priority to packet flow 70 if it determines that packetflow 70 represents a relatively uncommon communication. Further, managerserver 30 may associate two or more flows 70 into a combined(aggregated) flow 70 based on any suitable criteria such as, forexample, a correlation ruleset 33, source address, alert message 71, orflow priority. Aggregation allows system 10 to detect and respond tosubstantially long-term or multi-port attacks. Manager server 30 maythen communicate combined flow 70 to higher levels, comprising masterservers and global server 40, based on the flow priority. Once received,the appropriate upper level server 30 or 40 generates one or more HTMLpages, based on filtering ruleset 47, for communication to console 50.

If any manager server 30 (or global server 40) detects that one or morepacket flows 70 represent an attack on the enterprise, the respectiveserver 30 or 40 automatically generates a new response message 72 forimpeding the attack and assigns a higher priority to the combined flow70. Manager server 30 dynamically distributes the generated responsemessage 72, comprising a new signature or rule, to the lower and highernodes. To reduce system overhead, this distribution may not be to everynode in system 10. Instead, manager server 30 may communicate responsemessage 25 to certain nodes based on the respective port's communicationtype or any other suitable criteria. As described above, manager server30 may also attach a digital signature or other verification value toresponse message 72 to help ensure the security of the message. Once thelowest manager server 30 receives response message 72, it communicatesthe dynamic response message 72 to appropriate response message file 25for one or more sensors 20. Manager server 30 may also communicate a newprocessing message 73 to each sensor 20. Again, processing message 73represents processing instructions for sensor 20 such as, for example,to poll response message file 25 at certain time increments. Based onprocessing message 73, sensor 20 retrieves the dynamically generatedresponse message 72 from response message file 25 and impedes or detectssimilar future attacks.

The preceding description details various techniques for detectingattacks on an enterprise system using vertically extensible intrusiondetection system 10. While these techniques have been described inparticular arrangements and combinations, system 10 contemplates usingany appropriate combination and ordering of these operations to providefor vertical scalability using manager servers 30.

FIG. 2 illustrates an embodiment of a sensor 20 in accordance withsystem 10. As described above, while sensor 20 is illustrated as asingle module, the features and functionalities performed by thesemodules may be performed by multiple modules. Sensor 20 may be anyhardware, software, firmware, logic, or combination thereof operable toprocess communications from network 100 based on response message file25. Sensor 20 may be written in any appropriate computer language suchas, for example, C, C++, Java, Assembler, and others. Indeed, system 10contemplates that the processes and functionality of manager servers 30are substantially independent of the architecture of sensors 20.

Generally, sensor 20 processes input from network 100 and outputs packetflow 70, TCPDump archival data 74, and, when appropriate, IDMEF alertmessages 71. As described above, sensor 20 may also assign a priority topacket flow 70. According to certain embodiments, system 10 comprisesresponse message file 25, processing ruleset 26, and IDMEF plug-in 27for each sensor. Ruleset 26 comprises instructions, algorithms,processing messages 73, or any other directive which largely controlsthe processes of sensor 20. Ruleset 26 allows system 10 to incorporateand control a wide array of sensors 20 without substantial redesign ormodification. It should be understood that while processing ruleset 26is illustrated as external to sensor 20, ruleset 26 may be internalwithout departing from the scope of the disclosure. IDMEF plug-in 27 isan example plug-in that comprises instructions, algorithms, or any otherdirective that directs sensor 20 to output the proper format of certaindata such as, for example, IDMEF. Any formatting plug-in may be used inplace of or in combination with IDMEF plug-in 27 without departing fromthe scope of this disclosure.

In one aspect of operation, manager server 30 communicates processingmessage 73 to processing ruleset 26. One example of processing message73 stored in processing ruleset 26 comprises a command instructingsensor 20 to poll response message file 25 at regular intervals forupdates and expirations of response messages 72. Another example ofprocessing message 73 comprises a directive to sensor 20 to reset orinitialize itself to clear out old data or processes. Yet anotherexample of processing message 73 comprises an instruction to firstsensor 20 to shutdown and allow slave sensor 20 to assume the processesof first sensor 20. This example may allow system 10 to dynamicallyupgrade or replace first sensor 20 without a loss of protection at therespective port. Further examples include the processing messagecomprising an instruction to the sensor to poll the response messagefile to intercept one or more of the plurality of packets or to close anassociated port.

Sensor 20 monitors incoming data from external network 100 based onprocessing ruleset 26. Sensor 20 processes the data using responsemessages 72 (or rules) stored in response message file 25. In responseto detecting an attack, identified by one or more response messages 72,sensor 20 generates an alert message 71 and communicates the generatedalert message 71 to its respective manager server 30. Sensor 20 may alsogenerate a packet flow 70, using the various communications fromexternal network 100, and assign a priority to packet flow 70. Whetheran attack is detected or not, sensor 20 communicates the received dataup the hierarchy, via manager server 30, in either binary format or aspacket flow 70 for subsequent analysis.

FIGS. 3A through 3C illustrate various embodiments of correlation engine31 in accordance with system 10. It will be understood by those skilledin the art that correlation engine 31 may reside locally in managerserver 30, remotely on another computer server, or distributed acrossservers. It will be further understood that while correlation engine 31is illustrated as a single module, the features and functionalitiesperformed by these modules may be performed by multiple modules.Correlation engine 31 may be any software or logic operable to processmultiple communications from servant nodes. Correlation engine 31 may bewritten in any appropriate computer language such as, for example, C,C++, Java, Assembler, and others.

FIGS. 3A-B illustrate various embodiments of correlation engine 31operable to dynamically generate rules or signatures (for incorporationin response messages 72) and distribute the new rules in accordance withsystem 10. Generally, correlation engine 31 receives data from servantnodes, processes the data, and dynamically generates response messages72. Correlation engine 31 then communicates at least a portion of thedata up the system 10 hierarchy to upper-level manager servers 30 orglobal server 40 and distributes the response messages 72 to theappropriate servant nodes.

Correlation engine 31 is communicably linked with a correlation ruleset33 and a security table 34. Correlation ruleset 33 comprisesinstructions, algorithms, or any other directive that is used bycorrelation engine 31 to properly process packet flows 70 and alertmessages 71. Ruleset 33 allows manager server 30 to quickly changeprocessing rules without extensive redesign or modification. Thisadaptability allows easier scalability of system 10. Security table 34may be of any suitable format comprising XML tables, flat files,comma-separated-value (CSV) files, SQL tables, relational databasetables, and others. In one embodiment, security table 34 is amultidimensional data structure that comprises at least one signature orresponse message 72.

In one aspect of operation, illustrated in FIG. 3A, correlation engine31 detects an attack through a number of ways such as, for example,receiving alert messages 71 from servant nodes or aggregating packetflows 70 from multiple servant nodes to determine a multi-port ormulti-staged attack. In the first example, correlation engine 31receives a plurality of packet flows 70 and alert messages 71 fromservant nodes. Based on correlation ruleset 33, correlation engine 31associates a first alert message 71 with a first received packet flow70. In certain embodiments, correlation engine 31 associates alertmessage 71 with packet flow 70 using any suitable criteria such as, forexample, source address or destination address. Based on thisassociation, correlation engine 31 may dynamically generate a newresponse message 72 and distribute response message 72 to theappropriate servant nodes. In a second example, correlation engine 31efficiently and reliably analyzes data from multiple servant nodesthrough aggregation. Correlation engine 31 receives at least two packetflows 70 from servant nodes and then combines the first and second flows70 into third packet flow 70. Based on this aggregation, correlationengine 31 processes the combined data to detect an attack that is spreadamong the servant nodes. In this way, system 10 is can easily protectnumerous ports. Further, this technique of aggregation provides system10 with horizontally extensibility through easily adding sensors to newports without significant redesign or modification.

In another aspect of operation, illustrated in FIG. 3B, aftercorrelation engine 31 aggregates first and second packet flows 70 intothird packet flow 70, correlation engine 31 assigns a priority to thirdpacket flow 70 and passes third packet flow 70 up the hierarchy based onthe priority. For example, correlation engine 31 compares the first andsecond priority from the first and second flows 70. Then, in response tothe first priority not being less than the second priority, correlationengine 31 assigns the first priority to the third packet flow 70. Or, inresponse to the second priority being greater than the first priority,correlation engine 31 assigns the second priority to the third packetflow 70. In a second example, correlation engine 31 computes a priorityof the third packet flow 70 based, at least in part, on alert message 71or a detected uncommon event and assigns the computed priority to thethird packet flow 70. It should be understood that correlation engine 31may not communicate packet flow 70 to an upper-level manager server 30if the priority of packet flow 70 is not high enough.

FIG. 3C illustrates two correlation engines 31 a and 31 b, each residingon manager server 30 a or 30 b, respectively. The use of multiplemanager servers 30, or correlation engines 31, allows system 10 tocreate a hierarchy spanning internal network 80. As desired, system 10may easily add additional manager servers 30 to handle additionalworkloads or network ports. In this embodiment, manager server 30 a islogically higher in the system 10 hierarchy than manager server 30 b.Accordingly, manager server 30 a may be described as master server 30 ato aid readability.

Master server 30 a is communicably linked to manager server 30 b.Manager server 30 b is communicably linked to two servant nodes, firstand second sensors 20. It will be understood that this is forillustrative purposes only and that master server 30 a may include anynumber of servant nodes, comprising other manager servers 30 or sensors20 (not shown). As well, manager server 30 b may include any number ofadditional servant nodes, comprising manager servers 30 or sensors 20,without departing from the scope of this disclosure.

Each illustrated server 30 comprises database 32 a and 32 b,respectively. Database 32 may include any memory or database module andmay take the form of volatile or non-volatile memory comprising, withoutlimitation, magnetic media, optical media, random access memory (RAM),read-only memory (ROM), removable media, or any other suitable local orremote memory component. That is, server 30 may include non-transitorymachine-accessible and readable memory. In this embodiment, database 32comprises a correlation ruleset 33 and a security table 34, described inmore detail in FIG. 3A. Database 32 may include any other data such as,for example, an archival database table or other suitable data.

In one aspect of operation, each sensor 20 processes data from externalnetwork 100 as described in FIG. 2. Each sensor 20 processes the dataand outputs the data in binary format. Each sensor 20 may also reduceits respective packets to packet flow 70 and communicates it to managerserver 30 b. If sensor 20 detected an abnormal or problematic packet,then sensor 20 may, alternatively or in combination, create an alertmessage 71, which is also communicated to manager server 30 b, or assigna priority to packet flow 70.

Once manager server 30 b retrieves the data from first and second sensor20, manager server 30 b processes the information for possibledistribution to upper levels. In one embodiment, manager server 30 bretrieves binary data output from each sensor 20 and reduces portions ofthe data into packet flows 70. In another embodiment, manager server 30b receives first and second packet flow 70 from the first and secondsensor 20, respectively. Correlation engine 31 b processes the packetflows 70 based on correlation ruleset 33 to determine if any of the datarepresents at least a portion of an attack on the enterprise. Thisprocessing may include correlating one alert message 71 with one packetflow 70, aggregating two or more packet flows 70 into a third packetflow 70, or analyzing the priority of one or more of the packet flows70. Correlation engine 31 b may communicate the packet flow 70 to masterserver 30 a if an attack is detected, the priority of packet flow 70 ishigh enough, or based on any other suitable criteria. If correlationengine 31 b detects a portion of an attack, then manager server 30 b maydynamically generate a response message 72 based on the alert message 71or the packet flow 70. In this case, manager server 30 b would store thenew response message 72 in security table 34 and communicate newresponse message 72 to the appropriate sensor or sensors 20. Managerserver 30 b also may communicate response message 72 to master server 30a in order that the response message 72 may be distributed asappropriate. According to certain embodiments, manager server 30 b mayalso generate an HTML page based on the processing of packet flows 70.Each HTML page may be associated with one or more packet flows 70 andcommunicated to console 50 via master server 30 a.

Master server 30 a receives the plurality of communications from itsservant nodes, comprising manager server 30 b. Correlation engine 31 aprocesses the packet flows 70 based on correlation ruleset 33 todetermine if any of the data represents at least a portion of an attackon the enterprise that was not detected by manager server 30 b. Thisprocessing may include correlating one alert message 71 with one packetflow 70, aggregating two or more packet flows 70 into a third packetflow 70, or analyzing the priority of one or more of the packet flows70. Correlating engine 31 a may include additional functionality toensure proper control and monitoring of servant nodes, comprisingmanager server 30 b.

FIG. 4 illustrates an example embodiment of a graphical user interface(GUI) 52 in accordance with system 10. As described above, GUI 52provides an efficient and user-friendly presentation of data and eventsoccurring in system 10 to a user of console 50. GUI 52 may comprise aplurality of displays having interactive fields, pull-down lists, andbuttons operated by the user. GUI 52 may comprise a web browser (e.g.,Microsoft Internet Explorer or Netscape Navigator) that receives inputfrom system 10 and presents the appropriate HTML pages to console 50.While GUI 52 is described in terms of Hypertext Markup Language (HTML),GUI 52 may be developed using any user interface language such as, forexample, Extensible Markup Language (XML) or JavaScripts. It will beunderstood by those skilled in the art that GUI 52 may reside locally inconsole 50, remotely on another computer server, or distributed acrosscomputers. It will be further understood that while GUI 52 isillustrated as a single module, the features and functionalitiesperformed by these modules may be performed by multiple modules such as,for example, a web browser and a filtering module.

GUI 52 displays visual representations of one or more packet flows 70based, in part, on filtering ruleset 47. GUI 52 further allows a user tointeractively customize the view based on multiple groupings 56 orboundaries such as, for example, VPN groupings, firewall groupings,sites or other geographic locations, communication types, trust levelsof ports, or any other appropriate level of abstraction. For example,VPN groupings may allow the user to select only those packet flows 70received from a VPN (Virtual Private Network) or non-VPN connection andfirewall groupings may allow the user to select only those packet flows70 received from behind or beyond a selected firewall. These levels ofabstraction reduce the visual clutter and allow for more efficientviewing and detecting of possible attacks on system 10. The user mayselect one or more of groupings 56 to organize (sort, filter, or anyother appropriate processing) information as desired.

Accordingly, in certain embodiments, GUI 52 comprises a browser windowthat displays a parent HTML page comprising descriptive information 53and link 54 to a child HTML page for each packet flow 70. These HTMLpages are generated by system 10 on any computer or server in system 10comprising console 50, global server 40, or manager server 30.Descriptive information 53 presents relevant identifying data for eachpacket flow 70. For example, descriptive information 53 may includesource address, destination address, grouping information, the number ofpackets included in the respective packet flow 70, or any otherinformation suitable for identifying a particular packet flow 70. Link54 allows GUI 52 to conceal the packet headers and packet payloads ofeach packet flow 70 from the user of console 50. This provides a muchcleaner interface to the user, thereby resulting in an improved and/orquicker analysis. Each link 54 may be colored, such as red or green, torepresent the priority of packet flow 70. Further the data displayed inGUI 52 may be sorted by priority or any other criteria using a hashtable 75, illustrated in FIG. 5.

FIG. 5 illustrates an embodiment of hash table 75 used by graphical userinterface 52 in accordance with system 10. While described in terms ofglobal server 40, hash table 75 may reside on one or more computers orservers in system 10 comprising console 50 or manager server 30.Generally, hash table 75 allows system 10 to efficiently sort packetflows 70 without the many resources that would be needed to sort thevast amount of data included in each packet flow 70. For example, GUI 52may use hash table 75 to sort packet flows 70, for display to the userof console 50, using any criteria. Hash table 75 comprises hash values76 and arrays 77. Hash value 76 is any value that uniquely identifiespacket flow 70 and may be computed using any hashing algorithm such as,for example, MD-5. Each hash value 76 is associated with one array 77.Each array 77 comprises substantially all of packet flow 70 informationcomprising descriptive information, packet headers, packet payloads, andothers.

In one aspect of operation, global server 40 creates one unique hashvalue 76 for each packet flow 70 received from lower nodes. Each packetflow 70 may be stored in array 77 for easier processing by global server40. Global server 40 then sorts hash table 75 using any suitablecriteria and generates the HTML pages based on the sorted hash table 75.In another embodiment, global server 40 communicates the sorted hashtable 75 to GUI 52 to allow for a more dynamic generation of sorted HTMLpages.

FIG. 6 is a flowchart illustrating a method 600 for aggregating aplurality of flows in accordance with vertically extensible intrusiondetection system 10. In certain embodiments, method 600 enables system10 to easily scale manager servers 30, while detecting attacks ininternal network 80. Method 600 may be described with respect to modulesin system 10 of FIG. 1, but any other suitable system may use method 600without departing from the scope of this disclosure.

Data is received from external network 100 at a first sensor 20 in step602. At step 604 data is received from external network 100 at a secondsensor 20. As described above, the data is generally received fromcomputers residing outside of internal network 80, which is the networkprotected by system 10. Each sensor 20 processes the received raw dataaccording to any suitable intrusion detection technique at step 606. Atdecisional step 608, if an attack is detected, execution proceeds tostep 610. At step 610, each sensor 20 that detected an attackcommunicates one or more alert messages 71 to low-level manager server30. Next, or if an attack was not detected at decisional step 608,sensor 20 communicates the raw data to low-level manager server 30 usingany appropriate format. For example, system 10 contemplates sensor 20communicating a plurality of packets in binary format (such as TCPDump)or reduced to packet flow 70. Based on the type of sensor 20, sensor 20either outputs the data in binary format at step 612 or outputs the dataas packet flow 70 at step 616. In certain embodiments, in step 612sensor 20 may output the data in binary format to a binary file, thebinary file operable to be accessed by low-level manager server 30. Atstep 614, low-level manager server 30 either receives the binary outputfrom sensor 20 or retrieves the binary output from a binary file (notshown). Once low-level manager server 30 receives the binary output,manager server 30 combines the binary data into packet flow 70 based, atleast in part, on source IP address, destination IP address, priority,packet payload, or any other suitable criteria. Returning to step 616,sensor 20 outputs the data as packet flow 70 by communicating it tolow-level manager server 30. At step 618 manager server 30 receivespacket flows 70 for use by correlation engine 31. For archival purposes,sensor 20 communicates binary archival data 74 to global server 40 viathe manager server 30 hierarchy for storage in archive database 45 atstep 622.

Once sensors 20 have finished processing the data and the data isreceived at low-level manager server 30, manager server 30 correlatesalert messages 71 with packet flows 70 based on source IP address,destination IP address, or any other suitable criteria. At step 626,correlation engine 31 aggregates two or more plurality of packets (orpacket flows 70) into third packet flow 70. Once third packet flow 70 isgenerated, manager server 30 processes the third packet flow 70 todetect an attack that is occurring across at least first and secondsensor 20. If an attack is detected at decisional step 629, thenlow-level manager server 30 communicates an alert message 71 to the nextlevel in the hierarchy of system 10. For example, the next level may bean upper-level manager server 30 or global server 40. Method 600 thenproceeds to steps 631 to 634 where a priority is assigned to packetflows 70 being processed by manager server 30.

At decisional step 631, manager server 30 determines if any of theformer packet flows 70, which were aggregated into third packet flow 70,were assigned a priority by a servant node. At step 632, if one of theformer packet flow 70 were assigned a priority, manager server 30 maythen assign the highest priority from the former packet flows 39 tothird packet flow 70. Alternatively or in combination, manager server 30may assign a new priority to third packet flow 70 at step 634 based on anewly detected attack using a security table or correlation ruleset. Atstep 636, manager server 30 determines a verification value, such as ahash value, for third packet flow 70 and any associated communicationssuch as alert message 71. The now secure third packet flow 70 iscommunicated to an upper level in the hierarchy such as master server30, based on the priority assigned third packet flow 70. For example,low-level manager server 30 may not communicate third packet flow 70 tomaster server 30 if the priority is not high enough.

FIG. 7 is a flow chart illustrating a method 700 for dynamic rulegeneration in accordance with vertically extensible intrusion detectionsystem 10. Generally, method 700 provides system 10 with the ability tobe vertically extensible or scalable through dynamically responding toattacks or threats across multiple ports.

Data is received from external network 100 at a first servant node instep 702. At step 704, data is received from external network 100 at asecond servant node. At step 706, manager server 30 receives andaggregates first and second packet flow 70 a and 70 b, respectively,into a third packet flow 70 c based on source address, destinationaddress, priority, or any other suitable criteria. Manager server 30then dynamically processes aggregated third packet flow 70 c to detectif third packet flow 70 represents a multi-stage or multi-port attack oninternal network 80. Manager server 30 may process third packet flow 70c according to any suitable intrusion detection techniques. If an attackis not detected at decisional step 709, then execution ends. Otherwise,execution proceeds to step 710 where manager server 30 automaticallygenerates a response message 72 in response to the attack detected inthe processing at step 708. At step 712, manager server 30 associates ageneration date with the generated response message 72. Generally, thisgeneration date will allow a system 10 to discard older responsemessages 72.

Once response message 72 has been dynamically generated, manager server30 distributes the new response message 72 to all appropriate lowernodes and to the upper levels in the system 10 hierarchy in steps 714through 722. If one or more of the servant nodes is a sensor 20 atdecisional step 714, then manager server 30 automatically communicatesresponse message 72 to the appropriate response message file 25 forsensor 20. At step 718, manager server 30 communicates a processingmessage 73 to sensor 20 in order that sensor 20 appropriately receivesand utilizes response message 72. Manager server 30 automaticallycommunicates response message 72 to all the remaining servant nodeswhich may include other manager server servers 30 in step 720. At step722, manager server 30 automatically communicates response message 72 tothe upper levels in a system 10 hierarchy. It should be understood thatone or more of these upper-level manager servers 30 may distribute thenewly generated response message 72 to any respective lower nodes asappropriate.

FIG. 8 is a flow chart illustrating a method 800 for generating a userinterface using sorted packet flows 70 for use by graphical userinterface (GUI) 52. Generally, method 800 provides GUI 52 with auser-friendly, graphically efficient view of the vast amounts of datareceived across the enterprise and processed by system 10. While method800 is described using global server 40, it will be understood that anyappropriate module in system 10 may be used. Further, any other suitablesystem may use method 800 without departing from the scope of thisdisclosure.

Method 800 begins at step 802 where global server 40 receives aplurality of packet flows 70 from all lower nodes in system 10. Globalserver 40 generates a hash table 75 based on the received packet flows70, as described in more detail in FIG. 5. At step 806, global server 40sorts hash table 75 using any appropriate criteria. Global server 40then generates a parent HTML page for presentation to the console 50 viaGUI 52 in step 808. Execution then proceeds to steps 810 through 826,where global server 40 generates the links for child HTML pages for thevarious packet flow 70 received at global server 40.

At step 810, global server 40 retrieves the first hash value 76 in thesorted hash table 75. Global server 40 uses the retrieved hash value 76to retrieve the associated packet flow 70 in the array 77 at step 812.At step 814, global server 40 extracts the source address, destinationaddress, and determines the number of packets for packet flow 70. Oncethis information is extracted, global server 40 generates a link on theparent HTML page for the respective packet flow 70. At step 818, globalserver 40 may alternate the color of the link based on the priorityassigned to the respective packet flow 70. Global server 40 thengenerates a child HTML file or page for packet flow 70. At step 822 theextracted data is stored in the child HTML page. Global server 40 thenstores the packet flow 70 payloads in the child HTML file. At decisionalstep 826, global server 40 determines if there are more hash values 76in hash table 75. If there are more hash values 76 in hash table 75,then execution returns to step 812 and generates a new link in childHTML page for the new associated packet flow 70. Otherwise, if all thedesired hash values 76 have been processed, then execution ends.

The preceding flowcharts focus on the operation of example verticallyextensible intrusion detection system 10 described in FIG. 1, as thisdiagram illustrates functional elements that provide for the precedingscaleable techniques. However, as noted, system 10 contemplates usingany suitable combination and arrangement of functional elements forproviding these operations, and these techniques can be combined withother techniques as appropriate. Further, various changes may be made tothe preceding flowcharts without departing from the scope of thisdisclosure.

Although the present invention has been described in detail, it shouldbe understood that various changes, substitutions and alterations can bemade hereto without departing from the sphere and scope of the inventionas defined by the appended claims.

To aid the Patent Office, and any readers of any patent issued on thisapplication in interpreting the claims appended hereto, applicants wishto note that they do not intend any of the appended claims to invoke ¶ 6of 35 U.S.C. §112 as it exists on the date of filing hereof unless“means for” or “step for” are used in the particular claim.

1. Non-transitory machine-accessible and readable media comprisingsoftware that, when executed by a computer, operates to: receive aplurality of packet flows from a plurality of sensors at a plurality ofports between an external network and an internal network; aggregate theplurality of packet flows into an aggregated packet flow; dynamicallyprocess the aggregated packet flow to detect if one or more packets inthe plurality of packet flows represent an attack on the internalnetwork; automatically generate a response message in response to theattack, the response message operable to identify or impede the attack;and automatically communicate the response message to a response messagefile, the plurality of sensors operable to process packets received atthe plurality of ports from the external network according to theresponse message file.
 2. The non-transitory machine-accessible andreadable media of claim 1, wherein the software is further operable whenexecuted to communicate one or more processing messages to one or moreof the plurality of sensors.
 3. The non-transitory machine-accessibleand readable media of claim 2, the one or more processing messages toone or more of the plurality of sensors each consisting of one of thefollowing: an instruction to the sensor to poll the response messagefile; an instruction to the sensor to reset; an instruction to thesensor to shutdown; an instruction to the sensor to intercept one ormore packets; and an instruction to the sensor to close an associatedport.
 4. The non-transitory machine-accessible and readable media ofclaim 1, wherein the software is further operable when executed toassociate a generation date to the response message, the generation dateindicating a date of the automatic generation of the response message.5. The non-transitory machine-accessible and readable media of claim 4wherein the software is further operable when executed to: compare thegeneration date to an aging date, the aging date representing a pastdate that precedes a current date by a predetermined number of days; andin response to the generation date of the response message preceding theaging date, automatically remove the associated response message fromthe response message file.
 6. The non-transitory machine-accessible andreadable media of claim 1, wherein the software is further operable whenexecuted to: compute a verification value for the generated responsemessage; and associate the verification value with the generatedresponse message.
 7. The non-transitory machine-accessible and readablemedia of claim 6, wherein the plurality of sensors are operable toverify the response message based, at least in part, on the verificationvalue.
 8. The non-transitory machine-accessible and readable media ofclaim 1, wherein the software is further operable when executed tocommunicate the response message to each of a plurality of responsemessage files, each response message file comprising at least oneresponse message and being associated with at least one sensor.
 9. Thenon-transitory machine-accessible and readable media of claim 1, whereinthe software is further operable when executed to detect if one or morepackets in the plurality of packet flows is a stage of the attack, theattack comprising a plurality of stages.
 10. The non-transitorymachine-accessible and readable media of claim 9, wherein the generatedresponse message comprises a first response message, the first responsemessage operable to identify or impede the detected stage of the attack,and the software is further operable when executed to: automaticallygenerate a second response message, the second response message operableto identify or impede later stages of the attack; and automaticallycommunicate the second response message to the response message file.11. A method comprising: receiving a plurality of packet flows from aplurality of sensors at a plurality of ports between an external networkand an internal network; aggregating the plurality of packet flows intoan aggregated packet flow; dynamically processing the aggregated packetflow to detect if one or more packets in the plurality of packet flowsrepresent an attack on the internal network; automatically generating aresponse message in response to the attack, the response messageoperable to identify or impede the attack; and automaticallycommunicating the response message to a response message file, theplurality of sensors operable to process packets received at theplurality of ports from the external network according to the responsemessage file.
 12. The method of claim 11 further comprisingcommunicating one or more processing messages to one or more of theplurality of sensors.
 13. The method of claim 12, the one or moreprocessing messages to one or more of the plurality of sensors eachconsisting of one of the following: an instruction to the sensor to pollthe response message file; an instruction to the sensor to reset; aninstruction to the sensor to shutdown; an instruction to the sensor tointercept one or more packets; and an instruction to the sensor to closean associated port.
 14. The method of claim 11 further comprisingassociating a generation date to the response message, the generationdate indicating a date of the automatic generation of the responsemessage.
 15. The method of claim 14 further comprising: comparing thegeneration date to an aging date, the aging date representing a pastdate that precedes a current date by a predetermined number of days; andin response to the generation date of the response message preceding theaging date, automatically removing the associated response message fromthe response message file.
 16. The method of claim 11 furthercomprising: computing a verification value for the generated responsemessage; and associating the verification value with the generatedresponse message.
 17. The method of claim 16, wherein the plurality ofsensors are operable to verify the response message based, at least inpart, on the verification value.
 18. The method of claim 11 furthercomprising communicating the response message to each of a plurality ofresponse message files, each response message file comprising at leastone response message and being associated with at least one sensor. 19.The method of claim 11, further comprising detecting if one or morepackets in the plurality of packet flows is a stage of the attack, theattack comprising a plurality of stages.
 20. The method of claim 19,wherein the generated response message comprises a first responsemessage, the first response message operable to identify or impede thedetected stage of the attack and the method further comprising:generating a second response message, the second response messageoperable to identify or impede later stages of the attack; andautomatically communicating the second response message to the responsemessage file.
 21. A system comprising: a plurality of sensors operableto receive data from a plurality of ports between an external networkand an internal network, the plurality of sensors operable to processthe received data according to a response message file; the responsemessage file; a manager server communicably connected to the pluralityof sensors and to the response message file, the manager server operableto: receive a plurality of packet flows from the plurality of sensors;aggregate the plurality of packet flows into an aggregated packet flow;dynamically process the aggregated packet flow to detect if one or morepackets in the plurality of packet flows represent an attack on theinternal network; automatically generate a response message in responseto the attack, the response message operable to identify or impede theattack; and automatically communicate the response message to theresponse message file.
 22. The system of claim 21, the manager serverfurther operable to communicate one or more processing messages to oneor more of the plurality of sensors.
 23. The system of claim 22, the oneor more processing messages to one or more of the plurality sensors eachconsisting of one of the following: an instruction to the sensor to pollthe response message file; an instruction to the sensor to reset; aninstruction to the sensor to shutdown; an instruction to the sensor tointercept one or more packets; and an instruction to the sensor to closean associated port.
 24. The system of claim 21, the manager serverfurther operable to associate a generation date to the response message,the generation date indicating a date of the automatic generation of theresponse message.
 25. The system of claim 24, the manager server furtheroperable to: compare the generation date to an aging date, the agingdate representing a past date that precedes a current date by apredetermined number of days; and in response to the generation date ofthe response message preceding the aging date, automatically remove theassociated response message from the response message file.
 26. Thesystem of claim 21, the manager server further operable to: compute averification value for the generated response message; and associate theverification value with the generated response message.
 27. The systemof claim 26, the plurality of sensors further operable to verify theresponse message based, at least in part, on the verification value. 28.The system of claim 21, wherein: the response message file comprises oneof a plurality of response message files, each response message filebeing associated with at least one sensor; and the manager server isfurther operable to communicate the response message to each of at leasta subset of the plurality of response message files.
 29. The system ofclaim 21, wherein the manager server is further operable to detect ifone or more packets in the plurality of packet flows is a stage of theattack, the attack comprising a plurality of stages.
 30. The system ofclaim 29, wherein the generated response message comprises a firstresponse message, the first response message operable to identify orimpede the detected stage of the attack and the manager server furtheroperable to: automatically generate a second response message, thesecond response message operable to identify or impede at least one ofthe later stages of the attack; and automatically communicate the secondresponse message to the response message file.